ExecutionContext.global is CPU-sized, and blocking I/O (DataSource connection
acquisition via Doobie's connectEC, gRPC dispatch) on that pool starves all
request Futures waiting on the same small thread count.

Introduce BlockingIoExecutionContext, a fixed-size thread pool (default 50,
prop-overridable) dedicated to blocking JDBC and gRPC work. Replace global
at 6 sites:
- DoobieTransactor.scala (2 sites: fallback + update transactors)
- StoredProcedureUtils.scala (SP connector transactor)
- ProjectionDb.scala (projection transactor)
- ObpGrpcServer.scala (gRPC server dispatch)
- Boot.scala:1074 (production gRPC server creation)

Default pool size covers Hikari maximumPoolSize sum (main 20 + SP 20) with
headroom; override via blocking_io_pool.size prop if Hikari pools resize.

… sent

The password-reset endpoint (POST /management/user/reset-password-url) called
sendHtmlEmail and discarded the result, returning 'sent' unconditionally even
when the SMTP send failed. The caller (admin with canCreateResetPasswordUrl)
already knows the target user's email, so anti-enumeration does not apply here.

Switch to sendHtmlEmailEither and surface SMTP send failures as 500 responses
instead of lying that the email was sent. Restructure the for-comprehension to
hoist token generation before the send, and fail immediately on send failure.

Add test scenario: verify that when SMTP is misconfigured (closed port) and
test mode is off, the endpoint returns 500 with a message indicating the send
failed, not the successful 'sent' response.

Since the json4s migration, JValue itself extends scala.Product, so a raw
json.parse(...) result satisfies ResourceDoc example-body parameter types and
compiles. However, resource-docs serialization then reflects on it as a generic
case class instead of taking the JvalueCaseClass special-case unwrap path,
causing schema mismatches and potential asInstanceOf[JvalueCaseClass] failures.

All 20 affected UK OB v3.1 files share an identical private parseBody helper
used only for ResourceDoc example bodies (79 call sites total, never in handler
logic). Wrap the helper return in JvalueCaseClass(...) so serialization takes
the correct path.

This matches the earlier Berlin Group v1.3 fix (30afe2a) that resolved the
same root cause.